1. Statement of the Technical Field
The present invention relates to the field of distributed computing and more particularly to edge processing of application data.
2. Description of the Related Art
As business organizations deploy important business applications over the Internet, challenges arise in the form of processing delays and network latencies. Specifically, the placement of application content in a centralized server can compel users' requests to traverse multiple congested networks in an attempt to effectively interact with the application. As a result, this centralized approach to deploying applications on the Internet can hinder the attainment of scalability, reliability and performance levels that are considered “mission-critical” in the deployment of a business application.
In consequence of the inherent deficiencies of the centralized approach, there has been a recent trend to move more application processing functions to the edge of the network. In lay terms, the “edge” of the network refers to that portion of a publicly accessible network which is disposed communicatively closer to the end-user. While the positioning of servers and other network devices at the edge of the network can bear direct relation to the geographical positioning of the end-users, in some cases, the positioning of servers at the edge of the network can bear closer relation to the available communications bandwidth and the performance of network components linking end-users to the servers.
E-Business applications can experience dramatic performance and scalability improvements by off-loading applications to the edge of the network. Application off-loading can be achieved by distributing both applications and associated data to the edge of the network. In consequence, the load experienced by the centralized application and data servers can be reduced as can associated network traffic. Ordinarily, application off-loading can be accomplished by decomposing an application into edgable and non-edgable components, where the edgable components are those components which can be distributed to the edge of the network, while the non-edgable components are those components which cannot be distributed to the edge.
Notably, some components can be classified as non-edgable because of their dependence upon a back-end data store. Thus, by removing the back-end data store to the edge of the network, those previously non-edgable components which rely upon the back-end data store, too can be removed to the edge of the network. Two common methods of off-loading data to the edge of the network include data replication and query caching.
Data replication does not decompose an application into edgable and non-edgable components. Rather, data replication distributes an entire application to the edge of the network, along with that portion of the data store required for the operation of the application. The replicated portion of the data store can satisfy the majority of the data requirements for the edgified application. In those few cases where the data store cannot support the operation of the application, a query can be posed to the back-end data store.
Query caching, by comparison, involves the dynamic storage of query results based upon query rules which determine when the results of a query ought to be stored in a local data store at the edge of the network. Specifically, instead of replicating an entire data unit to the edge of the network, query caching involves only the caching of data in the local data store after the data has been retrieved from the back-end data store. The cached data can be used to satisfy subsequent queries without retrieving the requested data from the back-end data store. Of course, where the requested data cannot be satisfied by the cache, the back-end data store can satisfy the query.
Both data replication and query caching have associated therewith strengths and weaknesses. Data replication can satisfy any read query, but data replication can require substantial data storage to accommodate an entire database, including specific tables and views. Additionally, data replication requires extensive manual configuration inasmuch as a database administrator must identify the set of database tables which should be removed to the edge of the network. As the correct set of database tables can change over time, it can become difficult for the administrator to accurately maintain an appropriate data set at the edge of the network.
Query caching, by comparison, can be said to be “auto-configuring” and does not require as much administrative intervention. Also, query caching can require a limited amount of local storage to support the query cache. Yet, unlike data replication, query caching can involve some extensive processing, including not only determining when to store the results of a query in the query cache, but also when to retrieve data from the query cache rather than forwarding a query to the back-end data store. Specifically, in addition to parsing a query to identify the target database table and the requested operation, for instance a requested read or update operation, query caching can require a caching component to determine whether the query can be satisfied against the data set presently residing in the local data store.